Functionality doesn't have tests. Where do the tests go for the Set library?
Also, I don't like that intersection uses the getFirstFrom function to be able to use the reducer. Any idea how to better implement that?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49%. Comparing base (39f96ec) to head (d29bdf4).
Report is 15 commits behind head on main.

@@           Coverage Diff           @@
##              main   #1925   +/-   ##
=======================================
  Coverage       49%     49%           
- Complexity    6161    6162    +1     
=======================================
  Files          661     661           
  Lines        58698   58701    +3     
  Branches      8547    8548    +1     
=======================================
+ Hits         28958   28961    +3     
- Misses       27549   27552    +3     
+ Partials      2191    2188    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Very nice additions and necessary to the library. Thanks @linuswagner

Hi @linuswagner,

thanks for the nice addition. Could you at at least a few tests to the lang::rascal::tests::library::Set module?

@jurgenvinju I can't find the explanation of when in combination with pattern matching in the documentation, but I assume that in the case of

public bool isPairwiseDisjoint([set[&T] a, set[&T] b, *_]) = false when a & b != {};
public default bool isPairwiseDisjoint([set[&T] a, set[&T] b, *_]) = true;

it does not actually match pairs, but actually keeps a fixed, because isPairwiseDisjoint([{1,2}, {3,4}, {2}]) is true, should be false, and switching the order of the last two elements results in false again.
Or is the problem that I switched from a set to a list?

Hi @linuswagner,

thanks for the nice addition. Could you at at least a few tests to the lang::rascal::tests::library::Set module?

Perfect, that's what I was looking for. Thanks!

I've decided to make the operations stricter and throw exceptions when the input has not at least 2 elements.
The decision here is that I rather have something that is supposed to compare tell me if it can't compare rather than that it masks that.
On the downside, others will always have to check before calling the function, which causes more code and could cause weird cornercases (e.g. most of the times, the program produces inputs with at least 2 sets, but rarely, it gives less than that).

Is Rascal generally "better safe than sorry" or "you should better know what you're doing"?

Hi @linuswagner,
thanks for the nice addition. Could you at at least a few tests to the lang::rascal::tests::library::Set module?

Perfect, that's what I was looking for. Thanks!

Cool 👍🏼

I've decided to make the operations stricter and throw exceptions when the input has not at least 2 elements. The decision here is that I rather have something that is supposed to compare tell me if it can't compare rather than that it masks that. On the downside, others will always have to check before calling the function, which causes more code and could cause weird cornercases (e.g. most of the times, the program produces inputs with at least 2 sets, but rarely, it gives less than that).

Is Rascal generally "better safe than sorry" or "you should better know what you're doing"?

I think better safe than sorry. We don't want someone to base their conclusion on something where rascal was just sneakily hiding an error the user made. So if there is no default correct behavior for an input with 1 element, then yeah, throw an exception.